Summary

This fixes a small but visible end-position issue with the Aqara ZNCLBL01LM curtain driver.

After the curtain is told to fully open or fully close, the motor can stop at the real end of travel, but the device may still report a value that is just next to the end. For example, after opening to 100, it can later report 99 or 98. After closing to 0, it can later report 1 or 2.

Zigbee2MQTT then shows the curtain as not fully open or not fully closed, even though the command was for a full end position and the motor has already stopped.

#11911 already fixed one source of stale end-position reports from manufacturer attr 107. This PR handles the same kind of end-position drift when it comes from the other position paths this model uses:

• manufacturer attr 1055, which updates target_position
• closuresWindowCovering.currentPositionLiftPercentage, which updates position

The fix is intentionally narrow. For ZNCLBL01LM, the converter now remembers when the recent context is a real end position (0 or 100). While the motor is stopped, it only normalizes values very close to that remembered end position:

• 98 or 99 becomes 100
• 1 or 2 becomes 0

Safety

This does not blindly rewrite every 1, 2, 98, or 99.

Those values are only normalized when all of this is true:

• the device is ZNCLBL01LM
• the motor is stopped
• the converter has recent end-position context for 0 or 100
• the reported value is next to that same end position

If a user explicitly asks for a non-end position, including 1, 2, 98, or 99, the end-position context is cleared. That means those positions can still be used on purpose and should not be snapped back to 0 or 100.

The tests cover this for both normal and inverted cover configurations.

Scope

This PR only fixes the end-position settling problem after full open/close commands.

It does not try to fix separate partial-position behavior. In particular, explicit non-end-position commands are kept as non-end-position commands.

Testing

pnpm test test/lumi.test.ts -- --runInBand
pnpm run build
pnpm run check
pnpm test

I also tested the change with a temporary Zigbee2MQTT external converter override for ZNCLBL01LM:

• without the active override, a full open could still settle as 99/99
• with the active override, repeated full open/close checks settled as 100/100 and 0/0
• during the active override test, stopped publishes did not end with near-end 1, 2, 98, or 99
• explicit near-end commands were also checked to confirm they are not snapped to 0 or 100

AI Disclosure

Code and tests drafted with OpenAI Codex and reviewed, modified, and tested before submission.